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A METHOD, APPARATUS AMD COMPUTER 
PROGRAM FOR PROCESSING A QUEUE OP MESSAGES 



FIELD OF THE INVENTION 



The invention relates to data processing systems and more 
particularly to the processing of a queue of messages by such a system. 

BACKGROUND OF THE INVENTION 

It is often necessary to 'replay- a sequence of actions into a 
database or other system (such as a messaging system) . 

The sequence may be represented at various levels, e.g. log replay 
(as used in recovery) . transaction change replay (as used in database 
replication), or call replay (of an audit log of calls made, maybe at the 
SQL or stored procedure level or even at a higher application level) . 

Often, execution of the original actions was highly parallelised with 
database transaction and locking techniques assuring a logical order 
(sometimes only partial order) . This parallelism was essential to achieve 
good system performance. 

The logical order assured by the database transaction and locking 
techniques is represented in the sequence to be replayed. The problem is 
that the replay must be as fast as possible, and this also demands some 
degree of parallelism. However, it is still necessary to preserve the 
original logical sequence. 

By way of example, consider a system where the sequence to be 
• replayed is represented as a queue of work items. Each work item 
represents an original transaction, and contains a list of database record 

level updates. te.-be made . 

. .0-. -. , j !.•; : -., ; . 

(The : term update is used herein to include any operation that changes 
the database, including at least SQL INSERT, DELETE and UPDATE statements, 
and also any other updates such as data definition updates.) 

' The natural (much simplified) implementation of this is a single . 
•master transaction* thread: 



// master transaction thread 

for each work item // i.e. originating transaction 
get (e.g. read) work item 
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for each record update in work item 

apply update // e.g. record level update 
end for each update 

commit (work item read operation and database update operation) 
end for each work item 

However, each 'apply update 1 (which generally requires the relevant 
database record to be fetched (e.g. read) before the update can be applied) 
is likely to need data not currently held in a bufferpool associated with 
the database, so processing is stalled pending' the retrieval of the 
required data. Thus a problem exists in that processing throughput can be 
severely impacted. 

It will of course be appreciated that there is no corresponding 
problem with actually getting the update back onto the database disk since 
standard database l&zy write techniques may be used. 

Whilst this problem may apply to messaging systems it is less 
critical. As most queue activity is predictably at- the ends of the queues, 
a bufferpool of messages to be read may be appropriately predictively 
prefetched. In other words, the queue is typically read in a FIFO order 
. and thus ^cui -fc><=> productively and -ssqusnticLlly -p-rcf ctchGd * 

It is much more difficult to make such predictions in database 
systems. This is because records sequentially read from a database are 
typically scattered all over the database disk and work for a database is 
unlikely to require sequentially (i.e. contiguously) stored data records. 

US Patent 6092154 discloses a method of pre-caching data using tior^ad 
lists in a multimedia environment. A list of data (read requests) which 
will be required is passed by a host application to a datastorage device. 
In a multimedia environment the data required as a result of a read request 
can however be easily specified by the host application. In a database 
environment the host application may not be aware of the way in which the 
data. is stored, or even if it is, the host application may not be able to 
communicate this appropriately to the data storage device. Thus it is 
possible that some of the data required by a subsequent operation will not 
be available. 

US Patent 6449696 also discloses prefetching data from disk based on 
the content of lists with read requests. 
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SUMMARY OF THE INVENTION 

Accordingly the invention provides a method for processing a queue of 
messages, each message representing at least one request for an update to a 
database, the method comprising the steps of: browsing a message; 
extracting from a browsed message an update request; and sending a pretend 
update request to a database management system (DBMS) responsible for the 
database which is to be updated, the pretend update request composing an 
indication which indicates that the DBMS should not execute the update but 
should prefetch data that will be required when a corresponding real update 
is requested. 

Preferably the pretend update request is translated into a prefetch 
request; and required data is prefetched. 

Preferably a real update request is subsequently initiated, the real 
update request using prefetched data in order to execute. Preferably the 
message comprising the update is destructively got from the queue 
Preferably the destructive get is coordinated with the actual database 
update (two phase commit) so that a copy of the message is not deleted 
until confirmation of the update (s) has actually been received. 

in one embodiment a master thread performs the step of initiating an 
update request and one or more read ahead thread perform the step of 
browsing a message. 

Preferably the master thread is maintained at a predetermined 
processing amount behind a read ahead thread. This processing amount could 
be measured in terms of messages, updates etc. and helps to ensure that 
" data exists in memory when required. If the master thread gets too close 
there is the danger that required data may not -exist in memory when 
required for an update request to be executed. If on the other hand, the . 
roaster thread falls too far behind, then there is the danger that memory 
will become full and result in data that has not yet been used having to be 
overwritten . 

in one embodiment the prefetch request is in a predetermined form 
which is retained and an identifier is associated therewith in order that 
the retained predetermined form can be identified and used in subsequent 
performance of the real update request. Preferably the identifier is 
returned in response to the pretend update request. 

in one embodiment the pretend update is translated into a prefetch 
request in a predetermined form and associated with an identifier by the 



f 
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•DBMS. The identifier is received from the DBMS and is used in issuing a 
real update request. 

Preferably responsive to using prefetched data for an update request, 
a memory manager is informed that the prefetched data used may be discarded 
from memory. This helps to avoid memory from becoming over full. 

According to one aspect there is provided a method for pre-processing 
at a database management system (DBMS) update requests to database 
controlled by the DBMS, the method comprising: receiving an update request 
at the DBMS; receiving an indication at the DBMS indicating that the 

update request is a pretend update request and consequently that the DBMS 
should not execute the update but should prefetch data that will be 
required when a corresponding real update is requested; translating the 
pretend update request into a prefetch request; and prefetching required 
data based on the prefetch request. 



Preferably a real update request is subsequently received and already 
prefetched data is used to execute the real update request. 

In one embodiment the prefetch request is in a predetermined form and 
.is retained Ajn identifier is then -preferably associated with the retaixxed 
predetermined form 1 in order that the retained predetermined form can be 
identified and used in subsequent performance of the real update requests 
Preferably the identifier is returned in response to the pretend update 
request. 

In one embodiment the identifier is received with a real update 
request and is used in performance of the real update request. 

According to another aspect, there is provided an apparatus for 
processing a queue of messages, each message representing at least one 
request for an update to a database, the apparatus comprising: means for 
browsing a message; means for extracting from a browsed message an update 
request; and means for sending a pretend update request to a database 

management system (DBMS) responsible for the database which is to be 
updated, the pretend update request comprising ah indication which 
indicates that the DBMS should not execute the update but should prefetch 
data that will be required when a corresponding real update is requested. 

According to another aspect, there is provided an apparatus for 
Pre-processing at a database management system (DBMS) update requests to 
database controlled by the DBMS* the apparatus comprising: means for 
receiving an update request at the DBMS; means for receiving an indication 
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at the DBMS indicating that the update request is a pretend update request 
and consequently that the DBMS should not execute the update but should 
prefetch data that will be required when a corresponding real update is 
requested; means for translating the pretend update request into a prefetch 
request; and means for prefetching required data based on the prefetch 
request. 

According to another aspect there is provided a computer program for 
processing a queue of messages, each message representing at least one 
request for an update to a database, the computer program comprising 
program code means adapted to perform, when executed on a computer, a 
method comprising the steps of: browsing a message; extracting from a 
browsed message an update request; and sending a pretend update request to 
a database management system (DBMS) responsible for the database which is 
to be updated, the pretend update request comprising an indication which 
indicates that the DBMS should not execute the update but should prefetch 
data that will be required when a corresponding real update is requested. 

According to another aspect, there is provided a computer program for. 
pre-processing at a database management system (DBMS) of update requests to 
database controlled by the DBMS, the computer program comprising program 
code means adapted to perform, when executed on a computer, the method 
steps of: receiving an update request at the DBMS; receiving an indication 
at the DBMS indicating that the update request is a pretend update request 
and consequently that the DBMS should not execute the update but should 
prefetch data that will be required when a corresponding real update is 
requested; translating the pretend update request into a prefetch request ; 
and prefetching required data based on the prefetch request. 

" BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 .shows a database system in accordance with the prior art; 

Figure 2 illustrates the processing of the present invention in 
accordance with a preferred embodiment; and 

Figure 3 further illustrates the processing of the present invention 
in accordance with a preferred embodiment. 

DETAILED DESCRIPTION 

Figure 1 shows a database system in accordance with the prior art. 7 
system 10 has a queue of work items (messages) 20 for processing. Bach 
item of work represents at least one update to a record in database 30. 
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Queue of work 20 is read from right to left (FIFO order) and the data 
required from database 30 can thus be seen as data items (records) A, B, C, 
D.. (Note, each item of work may represent more than one update and may 
therefore require more than one record from database 30.) 

Apply application 40 reads from queue 20 and requests (via database 
interface 45) the appropriate data from the Database Management System 

(DBMS) 70. The DBMS includes a query processor 50 (including a parser) 
which requests data via bufferpool manager (not shown) from bufferpool 60 

(volatile memory) . If , as is likely, the data is not found within the 
bufferpool, then the data must be fetched from the database itself. 
Because the database may store thousands of records on disk and because the 
data is unlikely to be stored in a predictable order, system throughput can 
be severely impacted whilst the required data is retrieved into the 
bufferpool 60. In this example the queue, of work 20 requires records A, B, 
C and D to be fetched in that order, but the disk stores such records in a 
completely different order (A, C, D, B) . For this reason it is no use for 
the database to predictively prefetch records (i.e. typically in sequential 
order) - e.g. after reading A getting C. 

The present invention addresses this problem. Figure 2 illustrates 
the processing- of the -present* invention in accordance with a prsfsrred 
embodiment and should be read in conjunction with figure 1. 

A main read ahead thread in the apply application 40 browses each 
item of work from queue 20 (step 100) . As previously discussed, each work 
item comprises at least one update requested of database 30. For each such 
requested update a pioneer update thread is spawned (step 110) . Each 
pioneer update thread initiates (via the DBMS 50) the fetching of the data 
required into bufferpool 60 such that the appropriate update can be applied 
to the database 30 when requested (step 120) . - • 

The pioneer update threads do not make changes to the database 
themselves (they only read the data) and thus these may easily be applied 
in parallel. This parallelism permits the database to optimize its I/O 
pattern (in the same way as it would have during parallel execution of the 
original transactions) . 

Full implementation of a pioneer call preferably ensures that all 
relevant data, both for the record and indices, are read into the 
bufferpool. For example, take an update that sets the salary of person* 
1234 to 50000. This will probably involve the person record itself, and 
the index to the person table on person*. If there is an index on salary, 
then that is also preferably prefetched. 
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There are three mechanisms by which the pioneer updates (pretend 
updates) may be achieved: 

Mechanism A: Where the pioneer thread translates an update request into an 
associated prefetch request which is a query (i.e. a query to fetch the 
appropriate data rather than to actually perform the update itself) and 
issues that request to the database. Thus the pioneer call is simulated 
with a query on person* 1234. 

Mechanism B: Where the database interface 45 is extended to permit the 
pioneer thread to instruct the database that the call is a pioneer call 
(pretend update request) and not a x real' update. A pioneer thread 
extracts an update request from a work item (step 200 of figure 3); sends a 
the update request to the DBMS (step 210); and informs the DBMS (via an 
indication with the update request) that this is a pretend update- request 
so that the DBMS can translate the pretend update request into a prefetch 
request to fetch required data (step 220) . 

Mechanism C: Where the database interface 45 is further extended so that 
the calls from the pioneer thread (initiating prefetch requests) and from 
the master transaction thread (i.e. the thread which subsequently performs 
the requested updates) are explicitly associated; e.g. by passing a token 
(identifier) for the update between the calls. . Note, mechanism C is 
preferably an extension of mechanism B. 

Mechanism A involves no change to the database. However, it involves more 
work by the apply application in translating the update into a related 
query. There is also the possibility that the query will not force the 
database to read all appropriate data in the bufferpool; in the example the 
relevant part of index on salary may well not be prefetched. This is 
because the apply application may not fully understand how the database 
stores its information or may find it difficult to communicate an 
appropriate request to the DBMS. These issues are resolved in Mechanism B. 

In mechanism B the pretend update request is translated into a prefetch 
request and used to fetch data that will be required when a corresponding 
real update is executed. Because the DBMS creates the prefetch request, it 
is far more likely that all the required data for a particular real update 
request will be prefetched. The DBMS is aware of the way in which data is 
stored and is able to translate this effectively into an appropriate 
prefetch request. 

To explain Mechanism C more fully, when a pioneer update request is 
spawned by the apply application, it is sent to the query processor in 
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order for the query processor to parse the update request into an internal 
(predetermined) form. This internal form is used to determine what data to 
retrieve .from the database. Once the data has been retrieved this internal 
form could be discarded. However in doing this, when the master: thread 
wishes to action the real update, the update request will once again have 
to be parsed. 

To save time and processing power, the query processor can save a 
parsed internal form resulting from a' pioneer update request and this can 
be associated with a token which is passed back to the apply application. 
When the master transaction thread wishes to action the update request, the 
same token can be passed by the apply application to the DBMS and this can 
then be used to determine the appropriate parsed internal form of that 
request. This improvement removes the need for double parsing. 

The query token of Mechanism C is also preferably used by a 
buf ferpool manager (not shown) to determine when a prefetched data item is 
not longer needed. When the token is passed from the' apply application 
back to the DBMS in order for an update to be applied, the relevant data is 
retrieved from the buf ferpool and then the token is preferably passed to 
the buf ferpool manager to indicate thereto that the data associated with 
the. token mav.be ..removed.. from th« hnffpmnnl 
is data preferably removed from the buf ferpool.. 

This will reduce the risk of prefetched data being removed from the 
bufferpool even before it is required, or conversely of being held in the 
buf ferpool too long to the detriment of other data. 

It should be noted that whereas Mechanism A could be implemented by 
the apply application with no changes to the database implementation or 
interface, Mechanisms B and C require changes to the database interface and 
implementation. 

As alluded to above, the main read ahead thread operates ahead of a 
master transaction thread (also running in apply application 40) . The 
master transaction thread gets each work' item in the same way as the read 
ahead thread did earlier but this time however the item of work is actually 
removed, from the queue in order to actually action a requested update. 
Because the read ahead (and pioneer threads) has determined ahead of time 
the data that will be required by the master transaction thread, the 
necessary data should already have been fetched into the bufferpool 60. 
Thus the bufferpool manager should be able to retrieve the data requested 
by the master thread directly from the bufferpool 60 in order- that the 
requested update can be actioned. Since the requested .data is immediately 
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available, I/O is not stalled and thus performance is greatly improved. 
(As previously stated, standard lazy write techniques can be used to 
actually get the updated data back onto the disk.) 

It is important for reasons of performance that the master 
transaction thread does not get to close or fall too far behind of the main 
read ahead thread. (If the master thread falls too far behind then the 
buf ferpool may have to be overwritten with new data when the old data has 
not yet been used; if the master thread gets too close to the read ahead 
thread then the data may not have been properly prefetched into the 
buf ferpool before it is required.) 

It is thus preferable that there is some form of signalling between 
the main read-ahead thread and the master transaction thread to prevent 
this from happening. 

Preferably therefore the main read ahead, thread (and consequently its 
pioneer threads) is permitted to get no more than a predetermined amount 
(requiredReaaahead) ahead of the master transaction thread (e.g. measured 
in work items processed, updates processed or bytes processed) . 

Thus the apply application 40 has two counters, 
readaheadaiuountProcessea and mastexAmountProcessea. In the preferred 
embodiment, the requiredReadahead value is measured in terms of work items 
processed. Each time a read ahead thread moves to the next work item, 
readahead^ountProcessea is incremented. Each time processing, of a work 
item is completed by the master thread, masteriUnountProcessea is 
incremented. The main read ahead thread includes a sleep loop which causes 
any pioneer threads controlled by the read ahead thread to also sleep: 

while (reaaaheaaaaountProcessea-masterAmount-Processea > 
requirediteaaaheaa) sleep (10) 

in this way, the read ahead thread does not get too far ahead of the 
xnain thread. This is important because otherwise there is the danger that 
the buf ferpool 60 will become full thus necessitating the removal of data 
therefrom which may not have yet been used. 

The master thread includes also includes a sleep loop: 



while (reaaaheaaamouatProcessea-masterAxnountProcessea < 
requiredReadahead) sleep (10) 
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This ensures that the master thread does not overtake the main read 
ahead thread. 

Note, the completion of read ahead items may not occur in an orderly 
manner so it is difficult to precisely define how far the read ahead has' 
reached. Thus this signalling could be made more sophisticated to allow 
for precisely which pioneer updates are completed. 

It should be noted that in certain cases updates are dependent on 
each other in such a manner that execution of the first update changes the 
data that must be read in order to implement the later update- For 
example: 

[0] At start, Fred is in Department Y. 
[1] Move Fred to Department X. 

[2] Change the manager of Fred's Department to Bill 

The pioneer execution of [1] will read data for Fred into the 
bufferpool. This data will later be used when the master transaction 
thread executes [1] . The pioneer execution of [2] may happen before this 
update, and will therefore read data for Department Y (Fred's old 

..dftDfl T"1"Tn<=»ri t" ) -inhn. t-Vio biff ot^^a! . .u~».t.~..»~— 4-"u« — — *i . *. ^ -j? r ^ • •* -» 

- - * —x"— ~— • **v««^v *=..». , L.jiic jucax CAC^uuxuxi Ui. L^ J Will 

require data for Department X (Fred's new department) to be in the 
bufferpool. 0 

In these cases the master transaction thread may stall while 
executing the corresponding real update (i.e. because the required data is 
not in the bufferpool) . This will impair performance slightly but in 
general performance will nevertheless be much improved over the prior art 
methods. Note, it will not cause incorrect results (as out of order 
processing of the transactions themselves would have done) . 



Improvements /Variations 

Some improvements /variations on the basic idea described above will 
now be discussed. 

The embodiment discussed thus far uses a single read ahead thread 
with a new thread being spawned (created) for each pioneer update and 
terminated upon completion of its work. 

Thread* creation/termination is however an expensive process. Thus a 
thread pool may be used instead. In this embodiment, a pool of pioneer 
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update threads are continually available and when their work is done they 
return to the pool for use again at a later time. 

Another option (which can be used in conjunction with the thread 
pool) is to have more than one read ahead thread and for the multiple read 
ahead threads to share the work. In one embodiment a pool of read ahead 
threads is also used. 

The multiple read ahead threads also preferably signal to each other 
which work items they are responsible for. In this way one read ahead 
thread does not try to do work already completed (or in the process of 
being completed) by another read ahead thread - i.e. effort is not 
unnecessarily duplicated. 

A very simple implementation is one in which the first read ahead 
thread is responsible for work items 1, 4 and 7; a second read ahead thread 
browses work items 2, 5 and 8; and a third read ahead thread being 
responsible for work items 3, 6 and 9. 

Another improvement on the basic principle is to use batching. The 
original transactions execute in parallel so their log forces (for backup 
purposes) may boxcar (parallel batching) . This is useful as log forcing is 
processor intensive and holds up other processing until the force is 
complete . 

The master transaction thread is single threaded (this is important 
in order to preserve the logical order) and so boxcaring does not apply. 
Transaction batching may however be used with a commit operation being 
performed- only after a certain amount of processing has taken place 

(measured in terms of time, #messages, #updates, tbytes) . Since each 
commit operation also causes a force operation "to the log, transaction 
batching enables a larger amount of data to be forced in one go rather than 
the continual interruption to the master transaction thread of multiple 

(time consuming) log forces. 

Another option is to use paired master transaction threads. With a 
single master transaction thread, this thread would send a batch of updates 
to the DBMS for processing and then send a commit (or finalise command) 
thereto. The master transaction thread would then have to wait whilst the 
DBMS forced the update to the database disk. While waiting for control to 
be returned from the master thread (from commit), it is preferable for 
another thread to be processing another batch of updates - e.g. log force 
of each batch is parallelized with processing of the subsequent batch. 
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It will be appreciated that whilst the present invention has been 
described in terms of replaying a sequence of actions into a database it is 
not limited to such. It is applicable to any environment where there is a 
queue of messages to be processed involving random access to the data. 
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1 A method for processing a queue of messages, each message 
representing at least one request for an update to a database, the method 
comprising the steps of: 

browsing a message; 

extracting from a browsed message an update request; and 

sending a pretend update request to a database management system 
(DBMS) responsible for the database which is to be updated, the pretend 
update request comprising an indication which indicates that the DBMS 
should not execute the update but should prefetch data that will be 
■quired when a corresponding real update is requested. 



re 



2 



The method of claim 1 comprising the step of: 
translating the pretend update request into a prefetch request; and 
prefetching required data. 
3 . The method of claim 1 comprising the step of : 



initiating a real update request by destructively getting a message 
comprising the update request, the real update request using prefetched 
data. 

4 The method of claim 3, wherein a master thread performs the step of 
initiating a real update request and wherein one or more read ahead threads 
perform the step of browsing a message. 

5. The method of claim 4, comprising the step of: 

maintaining the master thread at a predetermined processing amount 
behind a read ahead thread. 

6 . The method of claim 2 wherein the prefetch request is in a 
predetermined form, 

the method further comprising the step of: 



retaining the predetermined form; 
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associating an identifier with the retained predetermined form in 
order that the retained predetermined form can be identified and used in 
subsequent performance of the real update request; and 

returning the identifier in response to the pretend update request. 

7. The method of claim 1, wherein the pretend update is translated into 
a prefetch request in a predetermined form and associated with an 
identifier by the DBMS, the method comprising the step of: 

receiving the identifier- from the DBMS; and 

issuing a real update request by sending the identifier with the 
update request . 

8 . The method of claim 1 comprising the step of : 

informing a memory manager that the prefetched data used may be 
discarded from memory. 

9. A method for pre-processing at a database management system (DBMS) 
update requests to database controlled by the DBMS;" the method "comprising: 

receiving an update request at the DBMS; 

receiving an indication at the DBMS indicating that the update 
request is a pretend update request and consequently that the DBMS should 
not execute the update but should prefetch data that will be required when 
a corresponding real update is requested; 

translating the pretend update request into a prefetch request; and 

prefetching required data based on th6 prefetch request . 

10. The method of claim 9 comprising the step of: 
receiving a real update request; and 

using already prefetched data to execute the real update request. 

11. The method of claim 9 wherein the prefetch request is in a 
predetermined form, . 

the method further comprising the steps of: 
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retaining the predetermined form; 

associating an identifier with the retained predetermined form in 
order that the retained predetermined form can be identified and used in 
subsequent performance of the real update request; and 

returning the identifier in response to the pretend update request. 

12. The method of claim 11 comprising the step of: 

receiving the identifier with a real update request; 

using the predetermined form associated with the identifier in 
performance of the real update request. 

13 . The method of claim 9 comprising the step of : 

informing a memory manager that the prefetched data used may be 
discarded from memory- 

14 Apparatus for processing a queue of messages, each message 
representing at least one request for an update to a database, the 
apparatus comprising: 

m ea ns for browsing a message; 

me ans for extracting from a browsed message an update request; and 

means for sending a pretend update request to a database management 
system (DBMS) responsible for the database which is to be updated, the 
pretend update request comprising an indication which indicates that the 
DBMS should not execute the update but should prefetch data that wxll be 
required when a corresponding real update is requested. 

15. The apparatus claim 14 comprising: 

means for translating the pretend update request into a prefetch 
request ; and 

means for prefetching required data. 

16. The apparatus of claim 14 comprising: 
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means for initiating a real update request by destructively getting a 
message comprising the update request, the real update request using 
prefetched data. 

17. The apparatus of claim 16, wherein a master thread performs comprises 
means for initiating an update request and wherein one or more read ahead 
threads comprise means for performing the step of browsing a message. 

18. The apparatus of claim 17, comprising: 

means for maintaining the master thread at a predetermined processing 
amount behind a read ahead thread. 

19. The apparatus of claim 15 wherein the prefetch request, is in a 
predetermined form, 

the apparatus further comprises: 

means for retaining the predetermined form to be used in subsequent 
performance of the update request; 

means -for associating an idcuiLifier with the retained "predetermined, 
form in order that the retained predetermined form can be identified and 
used in subsequent performance of the update request; and ° 

means for returning the identifier in response to the pretend update 
request . 

20. The apparatus of claim 14, wherein the pretend update is translated 
into a prefetch request in a predetermined form and associated with an 
identifier by the DBMS, the apparatus comprising: 

means for receiving the identifier from the DBMS; and 

means for issuing a real update request by sending the identifier 
with the update request. 

21. The apparatus of claim 14 comprising: 



means for informing a memory manager that the prefetched data used 
may be discarded from memory. 
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22 Apparatus for pre-processing at a database management system (DBMS) 
update requests to database controlled by the DBMS, the apparatus 
comprising: 

means for receiving an update request at the DBMS; 

means for receiving an indication at the DBMS indicating that the 
update request is a pretend update request and consequently that the DBMS 
should not execute the update but should prefetch data that will be 
required when a corresponding real update is requested; 

means for translating the pretend update request into a prefetch 
request; and 

means for prefetching required data based on the prefetch request. 

23. The apparatus of claim 22 compr ising : 

means for receiving a real update request; and 

means for using already prefetched data to execute the real update 
request . 

24. The apparatus of claim 22 wherein the prefetch request is in a 
predetermined form, 

the apparatus further comprising: 

means for retaining the predetermined form; 

means for associating an identifier with'the retained predetermined 
form in order that the retained predetermined form can be identified and 
used in subsequent performance of the real update request; and 

means for returning the identifier in response to the pretend update 
request . 

25. The apparatus of claim 24 comprising: 

me ans for receiving the identifier with a real update request; and 

means for using the predetermined form associated with the identifier 
in performance of the real update request. 
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26. The apparatus of claim 22 comprising: 

means for informing a memory manager that the prefetched data used 
may be discarded from memory. 

27. A computer program .for processing a queue of messages, each message 
representing at least one request for an update to a database, the computer 
program comprising program code means adapted to perform, when executed on 
a computer, a method comprising the steps of: 

browsing a message; 

extracting from a browsed message an update request; and 

. sending a pretend update request to a database management system 
(DBMS) responsible for the database which is to be updated, the pretend 
update request comprising an indication which indicates that the DBMS 
should not execute tbe update but should prefetch data that will be 
required when a corresponding real update is requested. 

28. A computer program for pre-processing at a database management system 
..(DBMS) of .update r«mi e *ts to - database- controlled by the DBMS, the coiuvuL«jc 
program comprising program code means adapted to perform, when executed on 
a computer, the method steps of; 

receiving an update request at the DBMS; 

receiving an indication at the DBMS indicating that the update 
request is a pretend update request and consequently that the DBMS should 
not execute the update but should prefetch data that will be required when 
a corresponding real update is requested; 

translating the pretend update request into a prefetch request; and 
prefetching required data based on the prefetch request. 
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ABSTRACT 



A METHOD, APPARATUS AND COMPUTER 
PROGRAM FOR PROCESSING A QUEUE OF MESSAGES 

The invention relates to the processing of a queue of messages, each 
message representing at least one reguest for an update to * 
me ssage is browsed and at least one update reguest is extracted from the^ 
.essage. The update reguest is sent to a datahase management system (DBMS) 
which is responsible for the database which is to be updated An 
Indication is also sent to the DBMS to indicate that the update reguest ,s 
a pretend update reguest and that the DBMS should not 
hut should prefetch data that will be reguired when a corresponding 
update is requested. 
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